Django의 MVT 패턴 vs 전통적인 MVC 패턴

Django를 실무에서 쓰게 되면서 "MVT 패턴"이라는 말부터 정리했던 글입니다. 결론부터 말하면 용어 매핑 표 하나로 끝나는 이야기인데, 진짜 어려운 건 그 다음이었습니다. 개념 정리는 앞에 그대로 두고, 실무에서 걸린 지점을 뒤에 붙였습니다.

1. 매핑 — 이 표가 이 주제의 전부다

혼란의 근원은 Django가 Controller에 해당하는 것을 View라고 부른다는 명명 하나입니다. Django의 View는 요청을 받아 로직을 실행하고 데이터를 넘기는 중간 처리자(=MVC의 Controller)고, 사용자에게 보이는 화면은 Template(=MVC의 View)이 담당합니다. "Django에는 Controller가 없다"가 아니라 이름이 다를 뿐 같은 자리가 있는 겁니다.

2. 요청-응답 흐름

1. 사용자의 HTTP 요청 수신
2. URLconf가 URL을 해석해 해당 View 함수 호출
3. View가 Model(ORM)과 상호작용해 데이터 처리
4. 처리된 데이터를 context로 Template에 전달해 HTML 생성
5. 생성된 HTML을 응답으로 반환

(참고: cupofcode — intro to django)

3. 역할 분리가 주는 것

• 로직(View)과 표현(Template)이 분리돼, UI 수정이 백엔드 코드를 건드리지 않습니다.
• 구성 요소별로 따로 테스트하기 쉽습니다.
• 구조가 프레임워크 차원에서 강제되니, 코드베이스가 커져도 "어디에 뭐가 있는지"의 예측 가능성이 유지됩니다.

실무에서 안 통했던 지점

여기까지가 정리고, 여기부터가 실전입니다. 매핑 표는 5분이면 이해되는데, 그 표가 답해주지 않는 질문이 실무의 전부였습니다.

1. "View가 Controller"라는 도식은 로직의 주소를 정해주지 않는다

패턴은 칸을 세 개 주지만, 실제 코드는 그 경계 위에서 씁니다. 목록 화면 하나에도 필터링·정렬·페이지네이션·권한 검사가 있는데, 이걸 View에 다 쓰면 뷰 함수가 수백 줄이 되고, Model 매니저로 내리면 재사용은 좋지만 추적이 어려워집니다. 이 고민의 연장이 함수형 뷰(FBV)냐 클래스형 뷰(CBV)냐였고, 실제 프로젝트에서 어느 쪽을 언제 썼는지는 따로 정리했습니다.

2. Template은 로직이 새어 들어오는 걸 막아주지 않는다

"Template은 표현만"이라는 원칙과 달리, 템플릿 언어에도 if·for가 있으니 로직은 조용히 템플릿으로 샙니다. 조건 분기 서너 개가 겹친 템플릿은 테스트도 못 하고 읽기도 어려웠어요. 실무에서 쓴 완충 장치는 두 가지였습니다:

• 모든 페이지에 필요한 공통 데이터(예: 헤더의 안 읽은 쪽지 수)는 각 View마다 context에 넣는 게 아니라 context processor로 — 실제 사례
• 반복되는 화면 조각은 템플릿 매크로로 공용화 — 실제 사례

둘 다 매핑 표에는 등장하지 않지만, MVT를 실무에서 굴리려면 이 층이 필요했습니다.

3. 복잡한 동적 UI 앞에서 Template은 뼈대까지만이다

서버사이드 렌더링이라 프로토타이핑은 빨랐지만, 트리 탐색·그래프 시각화·대시보드처럼 상호작용이 많은 화면은 결국 Template이 아니라 JS(D3, jsTree)가 담당했습니다. Template은 컨테이너와 초기 데이터 주입까지 하고, 나머지는 클라이언트 스크립트의 영역이었어요. MVT의 T가 커버하는 범위를 처음에 과대평가했다가, 화면 복잡도가 올라갈수록 "Django는 데이터와 뼈대, 화면 동작은 JS"로 역할이 재편됐습니다.

돌아보면

• 패턴 이름 논쟁은 실무에서 5분짜리 주제였습니다. MVT냐 MVC냐보다 "이 로직의 주소가 어디냐"는 질문이 매일 나왔고, 그 답은 패턴이 아니라 프로젝트의 컨벤션으로 정해야 했습니다.
• 원문의 6·7·8절은 같은 말 세 번이었습니다. 유지보수에 좋다, 협업에 좋다, 확장에 좋다 — 전부 "역할 분리가 좋다"의 반복이라 이번에 한 절로 합쳤습니다. 정리 글이 길어질 때는 내용이 는 게 아니라 같은 말이 늘어난 것일 수 있다는 걸 이 글 스스로가 보여주고 있었어요.